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EXCEPTION HANDLING UTILIZING CALL is executable code (typically an .exe file) which, after testing 

INSTRUCTION WITH CONTEXT a °d quality assurance, is passed to the user with appropriate 

INFORMATION installation and usage instructions, or to a factory for instal- 

lation in products with embedded computer systems. 
COPYRIGHT NOTICE 5 Development of programs is largely a trial and error 

process. Errors that emerge from this program development 
A portion of the disclosure of this patent document cycle can be divided into broad classes, including compile - 
contains material which is subject to copyright protection. ti me errors, linkage errors, runtime errors, and errors arising 
The copyright owner has no objection to the facsimile at runtime due to unexpected failures beyond programmer 
reproduction by anyone of the patent document or the patent control. Examples of such unexpected failures include fail- 
disclosure as it appears in the Patent and Trademark Office ures at external resources shared via a network, and failure 
patent file or records, but otherwise reserves all copyright 0 f the network. Proper development methodologies and 
rights whatsoever. quality controls will remove both compile-time errors (such 

as syntax and format violations) and linkage errors (such as 
BACKGROUND OF THE INVENTION ^ ^ bTSiX y ^ g ob2l i nam in g inconsistencies), but runtime 

Field of the Invention errors are less amenable to systematic elimination. Indeed, 

™_ ... . „ , . i the supreme importance of runtime errors stems from the 

The present invention relates generally to systems and _ . *V . r „ , , . . . m . 

. / c . 4 . i- f-i -. • • fact that they are usually discovered by, and provide major 

methods for increasing the reliability and improving the . t . / . , J . . * , , 

... - - & x / i , , u frustration to. the end user. Unless handled properly, runtime 

behavior of software programs More particularly, the • aborl ( , enninate) 0Xeculioni P lea ^ n J the sys . 

present invention relates to exception-handling systems and 20 P J tionabl ^ state an( / the ^ uncertain * s t0 wnat 

methods which assist software developers in the task of H and wfa4t dQ nejn ^ afe ma feasons for 

ensuring that programs operative on digital computers can mtract * bility 0 f the runtime error problem. First, it is 

recover from exceptional conditions and runtime program . j- . . 

H F B difficult to predict every user action during program execu- 

errors * „ lion. Although the conscientious programmer guides the 

Before a digital computer may ^accomplish a desired task, « ^ ^ hdpful menus and prompts> ^ aims l0 mscrt 

it must Receive an^appropriate.set of instructions- Executed code thal checks lhe validity of each user response, in 

by the computer's microprocessor, these instructions, col- prac tice, it remains a major programming challenge to 

lectively referred to as a "computer program," direct the anticipate and respond to arbitrary user input, 

operation of the computer. ^ Secondj i( is difficult, and often impossible, to predict the 

Computers essentially only understand "machine code," availability of the diverse hardware and software resources 

that is, the low-level instructions for performing specific required as program execution unfolds. For instance, the 

tasks interpreted as specific instructions by the computer's running program might request RAM (random access 

microprocessor. Since machine language or machine code is memory) and disk storage allocations at diverse points of its 

the only language computers actually understand, all other 35 execution, in the absence of which the program cannot 

programming languages represent ways of structuring usefully continue. Similarly, the running program might call 

"human" language so that humans can get computers to operating system, library, or other toutines that are, for 

perform specific tasks. various reasons beyond the programmer's control, un avail - 

While it is possible for humans to compose meaningful able at that moment. A common error, for instance, occurs 

programs in machine code, practically all software devel- ^ when a program seeks access to a file that is not available 

opment today employs one or more of the available pro- due to a network failure, for example. As with hardware 

gramming languages. The most widely-used programming resource exceptions, the program must either take evasive 

languages are the "high-level" languages, such as C++/C or action or simply terminate (exit or abort). Exceptions of this 

Pascal. type are especially common in modem computing environ- 

A~program~caUea^ ments where a set of independent user applications, or a set 

Ctions into the requisite machineianguage^ In the context of of independently executing threads within the same 

this translation, the program writte^irTttie high-level lan- program, must share the same resources, 

guage is called the "source code" or source program. The Apart from resource availability and unpredicted user 

ultimate output of the compiler is an "object module," which actions, a further source of runtime errors involves genuine 

includes instructions for execution by a target processor. 50 coding bugs not detectable during compilation or linkage. 

Although an object module includes code for instructing the For example, an arithmetical expression, accepted as legal 

operation of a computer, the object module itself is not in a by the compiler, may produce a runtime error for certain 

form which may be directly executed by a computer. values of its variable components. Typical cases are the 

Instead, it must undergo a "linking" operation before the "divide-by-zero" error and similar situations where the 

final executable program is created. 55 expression cannot be correctly evaluated. Such errors are 

Linking may be thought of as the general process of predictable and avoidable in theory. In practice, however, 

combining or linking together one or more compiled object traditional exception-handling solutions have involved a 

modules to create an executable program. This task usually hard-coded plethora of conditional tests of variable values 

falls to a program called a "linker." In typical operation, a before each expression is evaluated, followed by ad hoc 

linker receives, either from the user or from an integrated 60 routines to bypass invalid evaluations. The approach is at 

compiler, a list of object modules desired to be included in best tedious and prone to error. 

the link operation. The linker scans the object modules from Most of the high-level languages currently used for pro- 

the object and library files specified. After resolving inter- gram development exploit the concept of modularity 

connecting references as needed, the linker constructs an whereby a commonly required set of operations can be 

executable image by organizing the object code from the 65 encapsulated in a separately named subroutine, procedure, 

modules of the program in a format understood by the or function. Once coded, such subroutines can be reused by 

operating system program loader. The end result of linking "calling" them from any point in the main program. Further, 
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a subroutine may call a subroutine, and so on, so that in most defragmenting the heap) and then call funcB( ) again. But if 
cases an executing program is seldom a linear sequence of funcA( ) detects the "file not found" error, it may have no 
instructions. In the C language, for example, a main( ) means of handling this situation other than displaying a 
program is written which calls a sequence of functions, each warning. Unable to continue, funcA( ) must then return an 
of which can call functions, and so on. If all goes well, 5 error value to main( ). What, if anything, main( ) can do with 
control eventually returns to main( ). This nesting of func- this error will, of course, depend on the particular applica- 
tion calls simplifies the construction of programs but, at the lion. 

same time, complicates the handling of exceptions. The The merit of this "error chaining" scheme is that the stack 
essence of a function call is that it must pass any arguments is always unwound correctly, but there are several serious 
(or parameters) to the target function, transfer control to the 30 disadvantages. Each function in the chain is saddled with 
memory section holding the function's executable code, code that "looks" for exceptions occurring in its called 
return the result of the call, and at the same time, store functions. This code must also "decide" which exceptions 
sufficient information to ensure that subsequent execution can be handled and which ones have to be returned to the 
resumes immediately after the point where the original calling function. When the function calls are deeply nested, 
function call was made. This function-calling mechanism, as 35 and the number of different exception types increases, the 
is well-known in the art, is usually achieved by pushing and testing and chaining of exceptions becomes a major, error- 
pulling data and memory addresses on and off a stack prior prone programming headache. A significant obstacle to 
to, during, and after, the call. A stack is simply a dedicated well-formulated, easy-to-read, maintainable code is appar- 
portion of memory usually organized as a UFO (last in, first cnt from the simple example outlined above. If main( ) is left 
out) data structure. The stack is not normally manipulated 20 to handle an exception returned by funcA( ), it may need to 
directly by the programmer, but its contents are changed as know both the type of exception and where the exception 
a result of the function calls coded by the programmer. occurred. The type of exception is clear from the error code, 
Programs do have direct access to another portion of but the fact that it occurred in funcB( ) and not in funcA( ) 
memory, often called the heap, and a key element in excep- or, as the program is changed and extended, some other 
tion handling involves the management of this vital ^ function in the chain, is not immediately apparent without 
resource. additional error encoding. 

After a successful function call, the stack is unwound, that One response to this problem is the global (or long) go to 

is to say, all data which were "pushed" onto the stack are label instruction that can transfer control from any point of 

"popped" off in reverse order, leaving the stack in its pre-call any function to a routine residing anywhere in memory, at 

state ready for further function calls; execution resumes in 30 the address given by the identifier, label. Under this regime, 

the function which made the call. Note that, since function the funcB( ) of the preceding example need not return error 

calls can be nested to arbitrary levels, the stack must codes up the function chain, but, on detecting an error can 

maintain a vital, complex sequence of return values and send control directly to an appropriate exception handler, 

instruction pointers essential to the proper execution of the For example an exception handler routine at no-mem- 

program. Eventually, absent any problems, control ends 35 handler is presumed to handle all "insufficient memory" 

back in main( ), and after the final successful function call errors and, if necessary, use the value of sen to determine in 

in main( ), the program terminates. Any interruption to this which function the error occurred. In the current 

unwinding process leads to an unbalanced stack with unpre- terminology, funcB( ) "throws" the "insufficient memory" 

dictable results. For instance, a called function expects to exception, while the routine at no-mem-handler "catches" 

find its arguments in a particular section, known as the 40 the exception. 

function's stack frame, at the top of the stack; if the stack is This simple global go to approach has the merit of 

unbalanced, the function will pull off erroneous data, further offering a single, readable place for each exception handler, 

compounding the runtime error. but in practice it creates other problems. First, the standard 

Clearly, exceptional conditions and errors occurring in a go to instruction in the C and C++ languages operates only 

nested function can create a particularly difficult problem. 45 within a function; it lacks the required, long-distance power 

Several exception-handling approaches have been attempted to transfer control between functions. Second, as it stands, 

to address the problem. One approach, for instance, is to the direct transfer to a handler fails to correctly unwind the 

have each function return an error indication, either in a stack, as described earlier. Finally, and related to the first two 

separate variable, or as a special range of values for the objections, additional mechanisms to allow control to return, 

normal return value. The immediate onus of exception 50 if necessary, to the throwing function are needed. In order to 

handling then rests on the calling function. If the calling resume execution in the throwing function on those occa- 

function is unable to cope, it must return an error indication sions when the handler is able to "correct" the error, the 

to its calling function, and so on up the chain until either a exception-handling mechanism must allow the preservation 

function is reached that can handle the exception, or until and restoration of the state or context of the throwing 

main( ) is reached. If main( ) cannot correct the problem, it 55 function. 

terminates as gracefully as possible, perhaps displaying an When funcB( ) throws an exception, for example, its local 

explanatory message for the user. variables will hold particular values. As the name implies, 

As an illustration, suppose that main( ) calls funcA( ) the scope and existence of local variables is limited to the 

which, in turn, calls funcB( ). funcB( ) is programmed to "life-span" of the function: they disappear when the function 

return, say, zero for success or a positive number indicating 60 yields control. These local values and other parameters such 

the reason for failure. For example, funcB( ) might return 1 as the current values in the registers of the central processor 

for "insufficient memory," 2 for "file not found," and so on. constitute the state of funcB( ). In particular, the state 

funcA( ) always tests the value returned by fiincB( ). If this includes the stack status and the current IP (instruction 

test indicates success, funcA( ) carries on and eventually pointer) that marks the place in memory where execution 

returns control to main( ). If funcA( ) detects that funcB( ) 65 must be resumed. This state must be completely saved 

suffered an "insufficient memory" error, it may well be able before the handler is called, and then completely restored 

to correct the situation (by "collecting garbage" or by before execution of funcB( ) can be safely resumed. 



04/19/2004, EAST Version: 1.4.1 



US 6,289 ; 

5 

Some of the deficiencies of the global go to "solution" 
have been alleviated by the introduction of two Standard C 
library functions, setjmp( ) and longjmp( ). setimp( ) can be 
called in any function at the point at which control should be 
resumed if a matching longjmp( ) is called in another 5 
function. Typically, longjmp( ) is called when an exception 
is thrown. setjmp( ) takes as an argument the address of 
(pointer to) a programmer-supplied memory buffer in which 
the state of the current function will be saved. As discussed 
earlier, this state holds the processor registers, including the 10 
current instruction pointer IP (also called program counter 
PC), needed to resume execution immediately after the 
seTjmp( )l^riongjmp( ^unlike go to, can transfer control 
across different functions as follows: longjmp( ) takes as one 
of its arguments the same buffer address which is used in the 15 
matching setjmp( ). When longjmp( ) is called, it recovers 
the state saved by setjmp( ), and transfers control to the 
address found in the stored IP, namely the instruction 
following the setjmp( ) call. Further, longjmp( ) takes a 
second numeric argument which can be tested in the func- 20 
tion that called setjmp( ), thereby providing a mechanism for 
determining which particular longjmp( ) caused the jump. 

In funcA( ), funcB( ), or in any function they call, or in 
any function these functions call (and so on), the statement 
"longjmp(aJmpBuf, status); " ensures that the setjmp( ) in 25 
funcA( ) will be "recalled" under special circumstances in 
order to return value status in retval, following which, 
control will revert to the if (retval) line in funcA( ). In the 
absence of any longjmp( ) calls in subsequent functions, 
setjmp( ) returns zero (false), so that the if (retval) test fails. 30 
Thus, the setjmp( ) and longjmp( ) pair offer a global go to 
method for exception handling. Exception handlers can be 
encapsulated into any convenient set of functions, and after 
suitable handling, control can, if required, be safely trans- 
ferred back to the functions in which the exception occurred. 35 

However, the setjmp( )/longjmp( ) solution also has 
disadvantages. First, there is no guarantee that the function 
to which longjmp( ) returns is still active. In the previous 
example, it is possible that fna( ) has already returned, 
relinquishing its place on the stack, before a matching 40 
longjmp( ) is encountered. The only solution to this problem 
is to restrict setjmp( ) calls to the main( ) program. Second, 
the stack unwinding problem in the presence of nested 
setjmp( )s and longjmp( )s requires careful explicit program- 
ming. Finally, many popular program overlaying and virtual 45 
memory techniques employ special stacks, so that a func- 
tion's status is not completely stored by setjmp( ). All told, 
present-day approaches have failed to adequately address 
the problem of handling exceptions. 

The state of local variables are even more complex in 
languages like C++, where local variables or objects must 
have special associated functions, known as destructors, 
which must be called before they disappear. 

Some programming languages, for example C++ and 55 
other high-level languages have specified mechanisms to 
ease programming for exceptions, replacing and augmenting 
the previously described schemes. However, the implemen- 
tation of these mechanisms is complicated. There are prob- 
lems that lead to trade off situation between speed and space, 60 
which is well documented in the prior art. 

A specific problem relates to how to optimally map the 
location of the return address to the calling function, to 
information necessary to unwind the stack of calling func- 
tions to the point of a handler, or to the point of a decision 65 
to call the function "terminate ( )'\ The information which 
must be mapped to the return address comprises a pointer to 
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a table which holds necessary data for unwinding the 
stack-frame, that is restoring registers, restoring the stack 
pointer and information regarding the general stack-frame 
layout, and includes a description of allowed and caught 
exceptions in this frame. Alternatively, the table information 
could be compacted and stored instead of the pointer. The 
optimal layout of a stack-frame is highly dependent on the 
function which calls it, and cannot be guessed without more 
information than the return address and the value of the stack 
pointer and/or frame pointer as applicable to a particular 
implementation. It is desirable for implementation of excep- 
tion handlers to give as little overhead as possible when the 
exceptions are not thrown, as they are meant to be used only 
in exceptual situations. 

The predominant implementation in the prior art relates to 
program counter based tables. However, the time to look up 
the table of program counter ranges using a current value of 
the return address is relative to the size of the program. 
Given a binary search, which is typically used, the time of 
the search is logarithmic based on the number of calls in a 
program. Of course, this searching technique could be 
optimized using hash functions and the like known in the art. 
However no known implementation uses the bash function 
solution, probably because it would introduce an extra linker 
step and the time of the search is not considered important 
to many designers. 

An alternative implementation is based on providing 
information to locate the information by storing it at loca- 
tions that are addressed in the code which calls the exception 
close to the return address. However, the prior art techniques 
require program space or processor overhead in skipping the 
extra information in the calling code, using conventional 
calling techniques. For example, the skipping could be 
implemented at the return, with any instruction having no 
visible effect on the data flow such as a no operation NOP 
with an unused data or address field costing program space, 
or a move instruction which moves otherwise unused data, 
in which the unused field or data holds the desired infor- 
mation for the exception handler costing program space and 
processor overhead. See, Chase, Implementation of Excep- 
tion Handling, Part 1. The Journal of C Language Trans- 
lation (ISSN1042r-5721), Volume 5, Number 4, June 1994 
(second part in Volume 6, Number 1, September 1994). 

SUMMARY OF THE INVENTION 

According to the present invention, the^in-code' context 
data is incorporated into a special call instruction which is 
recognized by the processor. The information is skipped at 
the time of me<fooctii^call'and~re^ stack^ 
unwinding^ This special call instruction may^be imple- 
mented to run at no extra cycle costs compared to normal 
instructions, except for the external execution time depen- 
dencies from such machinery as a cache involved in the 
instruction fetching, since it would never be necessary 
during normal execution to actually access the information. 
The information is only accessed during exception handling. 

The amount of skipped information is preferably fixed, 
and holds enough data to include a pointer to information for , 
the specific stack layout, information about local try blocks, 
and clean up information, or enough to hold a pointer and 
compressed context data. The actual context data could be 
compressed using conventions such as addresses -never 
(being-odd or negative, so that the in-code^information 
includes actual data 'needed for stack unwinding. Thus, the 
skipped information could be regarded as a field in the 
instruction which causes the exception to be thrown. 
Alternatively, the skipping can be seen as a side effect of the 
instruction. 
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Accordingly, the present invention provides a new micro- at least a subset of the unw^d.informatibn, and/or a subset 

processor or other data processing system with a new of the layout "information. In an alternative system, the 

command labeled herein JSRC, standing for jump to sub- in -code context data comprises a pointer to a memory 

routine with context data. The new command has all of the location storing the information regarding a context for use 

features of the traditional jump to subroutine commands, 5 by the context-call-instruction. In alternative embodiment, 

plus an extra long word that contains an address to the the in-code context data comprises a plurality of bytes of 

context table, actual context data, or a combination of both. data, and includes a field for specifying a format for the 

Context information is used to keep track of which part of plurality of bytes. Thus for example the field indicates 

a given function code is executing when the exception is whether the plurality of bytes includes immediate context 

thrown. When the function is executing, and an exception Q data, and whether the plurality of bytes includes a pointer to 

occurs at some random point, the context table allows the context data in another memory location, 

system to determine what clean up is necessary before the According to other aspects of the invention, the determi- 

slack frame may be thrown away, and whether there exists nan t length of the in-code context data is predetermined, so 

any try-blocks that are active during the exception. For a that the instruction decode logic is capable of automatically 

given function, the context table is constructed which J5 upgrading the program counter without further processing, 

describes the effective layout of the function that are used for i n om er embodiments, the determinant length of the in-code 

these processes. (This contexT data is produced by the context data may be determined at the time of instruction 

rcompjler, which compiles function calls wrapped in a try- decode. 

block with a new instruction as outlined above containing -r^e present invention can also be characterized as a 

in-code context data. This instruction can be understood by 2Q met hod for processing instructions in the data processing 

contrasting it with the standard JSR instruction that does not system tha t comprises storing instructions from a set of 

include the in-code context data as described in more detail instructions in addressable memory. The set of instructions 

below. includes an context -call-instruction as discussed above. The 

(A stack u^wina^erm the exception manager unwinds the method includes fetching a sequence of instructions from the 

stack in a manner identical to the prior art, with the excep- ^ memory in response to an instruction pointer identifying an 

tion that it is able to locate context tables for each function address in the addressable memory. Next, a current instruc- 

popped from the slack during unwinding more quickly t ion is decoded including detecting the context-call- 

because there is no need to search the context records for a instruction. The instruction pointer is updated by the normal 

match. Rather, the in-code context data of the JSRC instruc- length of the context-call-instruction plus the determinant 

tion is used to go directly to the correct context record. 30 length of the context data in response to detection of the 

Thus the present invention can be characterized as a data context-call-instruction, else the instruction pointer is 
processing system responsive to instructions in a set of updated by the length of the current instruction, which 
instructions to execute a process, w The system comprises includes any operands if appropriate. Next, the context-call - 
instruction fetch logic which fetches instructions in a set of instruction is executed to call a function as a normal call- 
ins mictions to provide a sequence of instructions in response 35 instruction would. The called function normally returns by 
to an instruction pointer, or a program counter. The set of the same means as from a normal call-instruction. If 
instructions includes a context-call-instruction (e.g. JSRC) however, the called function does not return normally, but 
having a normal length followed by in-code context data rather an exception is thrown, which in turn happens to be 
having a determinant length utilized in execution of an not handled until stack unwinding reaches the point of this 
exception manager responsive to the context-call- 40 call, the stack unwinder will read the in-code context data, 
instruction. Instruction decode logic is coupled to the at an address in the addressable memory determined in 
instruction fetch logic and decodes a current instruction in response to a function of the instruction pointer. The in-code 
the sequence for execution. The instruction decode logic context data then holds information necessary to find any 
includes logic to detect the context-call-instruction. Execu- local exception handler, stack layout and cleanup informa- 
tion resources arc coupled to the instruction decode logic 45 tion. 

which execute the decoded instructions. Logic is couplccUo Accordingly, the present invention provides a computer 
the instruction fetch logic which updates the instruction- system for executing programs. The system comprises a 

pointer in response to the detection of the context-call- microprocessor and memory that includes a stack memory 

instruction by the instruction decode logic. In response to the f or storing function arguments and local data. A set of 

detection, the instruction pointer is jumped over the in-code 50 instructions in the microprocessor and executable by the 

context data to another instruction in the sequence so that the microprocessor provides for data flow and control flow 

in-code data does not effect the normal processing of the necessary to execute a representation of a program using the 

instruction. language defined by the set of instructions. One or more of 

According to another aspect of the invention, the system the instructions consist of a context-call-inslruction. The 
includes a program store coupled to the instruction fetch 55 special function call instruction is associated with a data 
logic in which instructions in the set of instructions are field for carrying in-code context data at a fixed point 
stored in locations accessible in response to the instruction relative to the perceived return address for the function call, 
pointer. The in-code context data is stored following the or other addressing side effects in the special function call 
context-call-instruclion by an oflset amount of zero or more instruction to that effect. The data field is large enough to 
bytes, and the logic which updates the instruction pointer 60 hold information regarding the layout of function 
jumps over a field of data at the oflset having a length equal arguments, local data and information necessary for unwind- 
to the determinant length. ing the function in processing synchronous or asynchronous 

As mentioned above, the sequenceof instructions conP exception information in one embodiment. Alternatively, the 

prises one or more functions that are characterized by data field is large enough to hold information necessary for 

unwind information, and layout information that is used to 65 retrieving the location of information regarding the layout of 

runwind the one or more functions for processing of the function arguments, local data and information necessary for 

context-call-instrucuon. The in-code context data comprises unwinding the function and processing synchronous or 
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asynchronous exception information. The data field is pro- system. The programs stored in system memory 24 and on 

cessed by the microprocessor in a manner that does not add disk memory, include a kernel or operating system (OS) and 

to the execution time of the named function call instructions typically a windows shell or interface. In some embedded 

specifically. A preferred embodiment is a variant of the JSR systems, no user interface is provided. One or more appli- 

instruction in the CRIS architecture of AXIS Communica- 5 cation programs, such as application programs or windows 

tions AB described in the 'AXIS ETRAK: CRIS Program- applications programs, may be "loaded" (i.e., transferred 

mers Reference', 1994 edition, available from "Technical from storage into memory) for execution by the system. The 

Publications, Axis Communications, Scheelevagen 16, programs 32 also include a development system 150 of the 

S-22370 Lund, SWEDEN" or from <cu-tpub@axis.com>, present invention for developing system and application 

which is incorporated by reference as if fully set forth 10 programs. As shown, the development system 150 includes 

herein. components which interface with the system through win- 

Other aspects and advantages of the present invention can dows shell, as well as components which interface directly 

be seen upon review of the figures, the detailed description through OS. 

and the claims which follow. Development system 150 in this example includes Bor- 

15 land Registered TM C++, available from Borland Interaa- 

BRIEF DESCRIPTION OF THE FIGURES tional of Scotts Valley, Calif. Application software on the 

„^ „ . ... , , . , ,. - other hand, can be any one of a variety of application 

FIG. 1 b a amplified diagram of a computer system ^ in£ . ^ ^ database sprcadsheet , 

including a processor for executing the context-call- ^ edi Ucati network appliance driver 

instruction of the present invention. 20 ^ olher ^ and embedded applicalions . 

FIG. 2 illustrates a software architecture for a develop- ^ cpu ^ ni aod , he 

ment system to be executed by the computer system of FIG. deve , m , tem 150> ^ mmpoaeats supporting 

1 or other compu er systems compiling software .Deluding ^ j for h Jf dlin Vxceptio.* accord- 

resources for the JSRC instruction of the present invention. . *[ . ca . • 

r ing to the present invention. 

FIG. 3 illustrates the layout of the JSRC instruction with 25 

regard to specific embodiments compared to a normal call c. Development System 
instruction. 

A . . . . f Shown in further detail in FIG. 2, the development system 

FIG. 4 is a simplified block diagram of a microprocessor ._ A . . . . A „ 

, v t . • i j- * c 150 of the present invention-includes a compiler 153, and a 

according , to ^ present mvention including resources for u ^ er 180 . ^ough an interface, the developer user supplies 

handling the JSRC instruction of the present invention. ^ ^ ^ ^ ^ 

FIG. 5 is a simplified block diagram of the program both comman d.line driven and Integrated Development 

counter update logic according to the present invention. Environment (IDE) interfaces, the former accepting user 

FIG. 6 is used for describing the processing of the JSRC commands through command-line parameters, the latter 

instruction in a microprocessor according to the present 35 providing menuing equivalents thereof From the source 

invention compared to a normal call instruction. code listings 161 and from headers/includes files 151, the 

FIG. 7 illustrates stack growth and context data used in compiler 153 "compiles" or^ggne rates object module(s),163. 

explanation of the present invention. The compiler 153 inserts the special JSRC instruction at 

FIG. 8 provides a flow chart of one example exception appropriate places in the code, and computes the associated 

manager according to the present invention. 40 context data. Depending on the format of the context data, 

the in-code portion of the context data is formulated and 

DETAILED DESCRIPTION placed in the object modules in a field having a predeter- 
mined length following the JSRC instruction itself The 

A. System Hardware balance of the context data is placed in a table with other 

45 context data associated with the program to be executed, and 
The present invention may be embodied on a computer a poinler ^ ^eluded in the in-code context data to the 
system such as the system 20 of FIG. 1, which includes a pos{{ioQ m the taMe at which lQe balance of lhe dala 
central processor 22, a main memory 24, and peripheral ^ inchlded In alternative systems, the context data for a 
devices 26 includmg for example an input/output controller, given ^ may ^ compressed and included in the in-code 
a keyboard, a pointmg device (e.g., mouse, track ball, pen ^ CQntexl data field comply. In llirn> linker ig 0 "links" or 
device, or the like), a display device, and mass storage (e.g., combines the object modules 163 with libraries 171 to 
hard disk). Additional input/output devices, such as a print- generale executable program(s) 165 (corresponding to block 
ing device, may be provided with the system 20 as desired. ^ 2 0 f F i G ; 1), which may bTexecuted by a target processor 
As shown, the various components of the system commu- (e processor 22 of FIG. 1). The standard libraries 171 
nicatc through a system bus or similar architecture. 55 mclude prev iouslyHcompiled standard routines, such as 
„ s ft graphics, I/O routines, startup code, and the like. A debugger^ 
ys em 0 ware 181 is provided for handling runtime errors in tht programs 
The following description will focus on the presently 165 according to the JSRC technique of the present inven- 
preferred embodiments of the present invention, which may tion. A description of the general operation of a representa- 
be advantageously applied to a variety of platforms and $0 live development system 150 of the prior art is provided with 
environments, whether command-line or GUI based, includ- Borland Registered TM C++, available directly from Bor- 
ing MS-DOS, Macintosh, UNIX, NextStep, Microsoft Win- land International. 

dows and the like. Therefore, the description of the exem- A debugger 181 may be provided to catch runtime errors 

plary embodiments which follows is for purposes of and/or exceptions thrown from within the programs 165 or 

illustration and not limitation. 65 libraries 171. The debugger may intervene in the actions of 

As illustrated in FIG. 1, executable programs 32 are an exception-handling module that may come from the 

provided for controlling the operation of the computer libraries 171 or be emitted as internally generated code 165 
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by the compiler 153. iTCe^exception^amlliiig^module 
(exception manager), caUed fronrcode emitted by the com- 
piler 153 when an exception is thrown , ma^ges u^wmding^] 
(if the staclcl cleanup of local objects, locating and executing" 
exceptidrfhandlers. The exception handling module is part . 
of the executable code 165. The exception handling module 
uses the context data according to the JSRC technique of the 
present invention. 

The exception handlers in the executable program 165 as 
well as the debugger module 181 are provided with 
resources to access the in -code context data in response to 
the throwing and catching of an exception. The location of 
the in-code context data for a thrown exception can be 
determined with a function of the value in the program 
counter of the microprocessor as described in more detail 
below. In a preferred embodiment, where the in-code con- 
text data is offset by zero bytes from the end of the JSRC 
instruction and its operands as normally present in the JSR 
instruction, and has a predetermined length of for example 
4 bytes, the location of the in-code context data is simply the 
program counter minus 4 bytes. An explanation of the 
control of the program counter is provided below. 

Detailed background concerning the problem of locating 
exception handling in the prior art can be found with 
reference to(thSri^atrNo^ and elsewhere. 

FIG. 3 illustrates the implementation of the jump to 
subroutine with in-code context data instruction JSRC of the 
present invention, as compared to the standard JSR instruc- 
tion at the assembly code and binary levels. 

In the first row 301, trK"asgmbl ycode ^label for the JSR 
instruction which carries as an operand the label 
"A„function." The operand "Adjunction" is represented by 
the value 0xl35ef382 in hexadecimal. The second row 302 
illustrates the binary value which would be stored in an 
executable file, with the least significant byte (82) first. The 
third row 303 illustrates the layout of the JSRC instruction 
according to the present invention which carries as param- 
eters the address of the function "A_function" and the 
in-code context as the address of the context table labeled 
"This_conlexl_lable."The binary value for this instruction 
is illustrated in row 303. The address of (his context table in 
hexadecimal is represented by 0x55 77a acc. 

An alternative embodiment of the instruction carries a 
reference to a register rather than a parameter as an argument 
in the JSR and JSRC instructions. Thus in row 305 the 
standard JSR instruction carrying as argument the register 
address R5 is illustrated. In this embodiment for the JSR 
instruction, the reference to register R5 is carried in the least 
significant byte in the instruction. The binary representation 
of this is illustrated in row 306. In row 307, the JSRC 
instruction according to the present invention which carries 
the register address R5 as an argument is illustrated. The 
binary representation is shown in row 308. 

For this example, the standard hexadecimal representation 
of the JSR instruction is 0xbd3f and the standard hexadeci- 
mal representation of the JSRC instruction is 0x3d3f. 

In an embodiment carrying compressed context data, the 
field may be determined according to the following 
example. Here, we assume there are seven registers used for 
general purposes, named rO up to r6. Assume that the context 
information we need for this call-point includes stack layout, 
try-block-context, local objects that need destruction, and 
exception handlers aka. catch-blocks. 

Assume that the common case is that there are no objects 
that need destructors to be called, no "open" try-blocks or 
catch-blocks for this call-point, so using the compressed 
format implies that those lists are empty. 
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Assume also that the stack-pointer is used as the base for 
this context. 

Those 31 bits now just have to encode the stack layout, 
which for the preferred embodiment would be: 

The offset to the return-address of the caller. 

What registers are saved. 

Amount of stack allocated for local variables. 

Assume that the normal case is that the stack-frame is no 
larger than 16 Kbytes, so we take 14 bits for the offset to the 
return- address of the caller. Local variables may then also 
lake up 16 Kbytes; that's another 14 bits. The number of 
saved registers are most often less than seven, (often con- 
tinuous from rO and up, stopping at r6), so we need only 
three bits (zero=no registers) for that. 

bit#: Meaning: 

0 The context is in compressed form=l, pointer to table- 
0. 

Assuming bit 0 is 1: 

1 ... 14 Offset of callers saved PC (the return-address). 
15 ... 28 Amount of local variables, counted in bytes (the 

adjustment needed to the stack-pointer). 

29 ... 31 Coded information on saved registers: none, rO, 
rO . . . rl, . . . , rO . . . r6 

The second field may be deduced from the first and the 
third field, so more information can fit here, perhaps some- 
thing from the previously assumed empty lists. For example, 
perhaps 15 bits could be used as an of&et from this location 
in the code to a simplified table. 

This compressed formal then means we do not have to 
emit any table with this information for most of the call- 
contexts, and so can save a lot of memory. 

Thus, the Ccompiler inserts the JSR code~at appropriate 
places in the object modules~being compiled if the in-code 
context data is not appropriate for the particular instance. 
For instances in which the JSRC in-code context data is 
appropriate, then the compiler inserts the JSRC instruction 
in the form illustrated. 

In execution of the instruction, the program counter and 
instruction fetch logic associated with the processor using 
this technique are responsive to detection of a JSRC instruc- 
tion to increment the^program- counter^ or other equivalent 
instruction pointer, around thTih^codecontext data that does 
not need to be read in normal processing. Thus, FIGS. 4 and 
5 illustrate the structure of a microprocessor configured to 
execute the JSRC instruction, and the logic for incrementing 
the program counter in the context of a JSRC instruction 
according to the present invention. Thus, FIG. 4 is a sim- 
plified diagram of a processor or CPU implemented accord- 
ing to the present invention. It includes a plurality of 
functional units 400. The functional units 400 include execu- 
tion units for arithmetic and logic functions, instruction 
decode logic that includes logic that detects and decodes 
JSRC instruction of the present invention, program counter 
update logic (PC update), and instruction fetch logic which 
is used for producing a sequence of instructions for execu- 
tion by the processor in response to the program counter and 
the results of execution of other instructions. Thus the 
instruction fetch logic provides for management of instruc- 
tion caches, branch instructions and the like. 

The functional units 400 are coupled to the system bus 
across line 401 through a bus interface. Line 401 may 
constitute one or more buses for carrying input data and 
supplying output data. Also, instructions from an instruction 
store and addresses for retrieving data and instructions are 
supplied across the bus_interface. Within the processor, 
typically Q plural jty_dfL.general~registers 402 _commonjy 
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{referred to as a register file is provided. Typically it is a three 
port memory unit which supplies operands on lines 403 and 
404 to the functional units, and receives results to be stored 
from the fictional units across lines 405. 
In FIG. 4,*he program counter 406 is shown as a register 

^independent of the general register file 402: Of course in 
various embodiments it could be considered, as part of the 
register file. The program counter 406 is coupled to the 
program counter update logic within the functional units 
across line 407 and feeds the program counter value back to 
the functional units for use by the instruction fetch logic and 
other functional units as appropriate across line 408. 

Thus according to the present invention, the functional 
units of the processor are adapted to recognize the JSRC 
instruction and control the updating of the program counter 
in response. 

FIG. 5 illustrates the program counter update logic in a 
simplified version for use in the system of FIG. 4. As 
described above with respect to FIG. 3, the JSR and the 
JSRC instructions come in a variety of formats for various 
addressing modes, including a first format that carries an 
operand in the code, and a second format which carries a 
register identifier as part of the instruction. 

The PC update logic illustrated in FIG. 5 consists essen- 
tially of an adder 500 which adds the value PC of the 
program counter from line 501 with the output of a first 
selector 502 which is controlled by a signal indicating that 
the JSRC instruction has been recognized, and the output of 
a second selector 503 which is controlled by a signal 
indicating that the instruction carries an operand that takes 
up more space than the instruction, or not. Thus, in the case 
of an instruction which does not carry an operand the output 
of a selector 503 is the instruction length, for example 2 
bytes. In the case that the instruction carries an operand, and 
the decode logic has read the operand then the output of 
selector 503 is the length of the operand, which for the 
example of FIG. 3 is 4 bytes. If the instruction is a JSRC 
instruction, the output of the selector 503 must be combined 
with the length of the in-code context data. Thus the selector 
502 selects either zero bytes if the JSRC instruction is not 
recognized or the predetermined context length if the JSRC 
instruction is recognized. These three values are added 
together by adder 500 and supplied back to the program 
counter as the updated program counter value. This updated 
program counter value in the case of JSRC instruction is 
utilized by the exception manager to find the in-code context 
data. 

In the embodiment of FIG. 5, the context length is a 
predetermined value associated with a particular JSRC 
instruction. In various embodiments, the length of the con- 
text data can vary according to the needs of a particular 
implementation or instance of the jump to subroutine 
instruction. Thus, the jump to subroutine instruction may be 
provided in more than one instance for various context 
lengths. In this case, the program counter update logic would 
have to recognize the particular instance of the JSRC 
instruction and add the appropriate context length. 
Alternatively, the JSRC instruction could carry as a param- 
eter a value which is equal to the context length to be added 
to the program counter. In this case, the context length might 
be retrieved from the general purpose registers where oth- 
erwise provided by the functional units of the processor. 

FIG. 6 is utilized to describe the process of executing the 
JSR and the JSRC instructions according to the present 
invention. In the first row 600, the JSR instruction is 
described. As the processor executes the instruction it first 
reads the instruction, decodes the instruction and updates the 
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program counter to the location following the instruction in 
cycle 1 up to cycle Nl. From cycle Nl up to cycle N2 the 
operands if any carried with this instruction are read. The 
program counter is updated to the location after the oper- 

5 ands. In cycle N2 up to cycle N3, the program counter is 
stored at the location of the return address for the subrou- 
tines and any related entity such as the stack pointer are 
updated according to the standard execution processes for 
the JSR instruction. In cycle N3 up to N4 the next instruction 

10 is read at the target of the call, and the subroutine is 
executed. 

According to the JSRC instruction, in cycle 1 up to cycle 
Nl, the instruction is read and decoded. The program 
counter is updated to the location after the instruction. In 

15 cycle Nl up to cycle N2 the operands are read and the 
program counter is updated to the locations of the operand 
plus the length of the in-code context data which in this 
embodiment would be^a fixed (Size>In cycle N2 up to cycle 
N3, the program counter is stored at the location of the return 

20 address and any related entities are updated. In cycle N3 up 
to cycle N4, the next instruction is read at the address of the 
call and the subroutine is executed. 

However, the exception manager needs to read the 
in-code context data, using a function of the program 

25 counter value to find the data. In particular, the beginning of 
the data will be determined by a function which is equal to 
the value of the program counter plus an oSset of zero less 
the length of the code word. In this manner, the in-code 
context data is automatically associated with the calling 

30 function. Also, the in-code context data does not interfere 
with normal processing or cost extra cycles in normal 
execution. 

Accordingly, the context or a pointer to the context is 
located at the offset of the return address less 4 in the 

35 preferred embodiment. Once the return address is found, the 
exception manager finds the in-code context data without 
requiring searching tables and matching values. 

The information in the in-code context data in this 
embodiment is 4 bytes or 32 bits. The 32 bits is either 

40 context or context pointer, or a combination of both. In the 
preferred embodiment there is a preferred alignment of 32 
bits for data. This assumption can be used to encode at the*, 
Cieasr significant bits whether the rest of the 32~bits are a 
pointer or actual compressed context data with some infor- 

45 mation fixed. Thus, pseudocode for an exception manager 
and stack walker function which could utilize the JSRC 
in-code context data of the present invention follows: 

so 

C Axis Communications AB 1998 

/* Get a pointer to the context information for the function 

with the return address of "pc_retu m_locatio a". 
Remember, "char'* is byte-sized 

55 ( 8 bits >- 

If the context is of the compact kind, expand it into the 
structure in "expanded context", before returning a 
pointer to "that* (overwritten at next call). "/ 
void *f(void •■return_pc_stack_location) 

{ 

static struct exception_context expanded_coniext; 

/• Offset -1 for a pointer-size object means -4, counted in bytes. */ 

void "contexl_or_poinlcr - return pc__slact location{-lj; 

/" Since all exception-tables are aligned on addresses that are 

a multiple of two, we code the "compacted context" property 
in the lowest bit in the plausible pointer; if it is zero, then this 
is a pointer, if 1, it is a compacted context. */ 
°5 if ((((unsigned long int) context_or_pointer) & 1) — 0) 

{ 



04/19/2004, EAST Version: 1.4.1 



US 6,289,446 Bl 
15 16 

-continued -continued 



O Axis Communications Afi 1993 

/* It was a pointer, just return it, */ 
return context_or_pointer; 

} 

else /* Compacted form. V 
{ 

. . . Expand the compacted form, from "context_or_po inter'* into 

4 *expanded_context" . . . 
return &expanded_context; 

} 

} 

/* We happen to know where the return-address to the caller of this 

particular function (staci_ walker) is; it's just at the 
stack-pointer "sp", offset -8. 
Portability issues omitted for brevity. */ 

void stack„waIker(void) 

{ 

void* *retum_pc_location; 

struct exception_context •contextp; 

/" Inline-assembler magic for getting the stack-pointer value. */ 
asm(**move.d sp, %0" : **»rm" (retum_pc_location)); 
return pc „ localion-8; 
contextp - f(retum_pc_location); 

/* Just loop through the callers (assuming none have specified 

"throwO"), starting from this function, using the 
context- tables. Print the return-address of each as an 
example. 

Don't worry about compressed context information, **f(PC)" 
handles that. 

The "root" call to **main()" and global constructors is 
marked with a "zero" context; we will get it as NULL. 
When we do, stop there. 
(BTW, if the search for a handler reaches that, 
"terminateO" is called). 

This same loop-construct can be used to implement the 

loop-part of stack-unwinding and 

exception-handler-search. "/ 
while (contextp !=NULL) 
{ 

printf "Called from: % p *\ *return_pc_locaUon); 

/• Update retura_pc_localion and context associated with 

that caller. V 

return_pc_location 

-retura__pc_lcation + contextp- >oGfset_of_return_ad dress; 
context+f(retum_pc_location); 

} 



The compiler in a preferred embodiment of the present 
invention for the C++ language is responsible for generating 
exception tables. According to the present invention, the 
compiler is modified to provide a portion of the exception 
tables or a pointer to the exception tables as in-code context 
data in connection with the JSRC instruction. 

The following provides an example pseudo-code of a 
program in which the JSRC instruction of the present 
invention would be utilized according to the C++ language. 



1 class To_be_thrown 

2 { 

3 public: 

4 To_be_thiown(char •message) : thc_mcssage( 'message) {} 

5 ~To_be_thrownO {} 

6 coast char 'message^ { return the_message; } 

7 private: 

8 coast char 'the message; 

9 }; 

10 class Fee 
« { 

12 public: 

33 Foo(int a) : value (a) { printf ("Foo:% d ctor called\n", value); } 

34 ~FooQ { printf ( M Foo:% d dtor called\n'\ value); } 
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15 


private: 


16 


int value; 


17 


}; 


18 


extern void wont_throw(consl char *) throwQ; 


19 


extern void ma>^c_throw(const char "); 


20 


extern void bdirect(void (")(const char *), const char •); 


21 


void middlemanO 


22 


{ 


23 


Foo foo_l(l); 


24 


ma ybe_tfirow("Th is"); 


25 


wont_l hrowCThaf); 


26 


indirect(maybe_throw, "Whatever"); 


27 


Foo foo_2(2) 


28 


maybe_throw(*'Something"); 


29 


} 


30 


void indirect(void ("f)(const char *), const char "sc) 


31 


{ 


32 


chare[lOt 


33 


stmcpy(s, sc, 9); 


34 


f(s); 


35 


} 


36 


void doitfvoid) 


37 


{ 


38 


try 


39 


{ 


40 


middlemanO; 


41 


} 


42 


catch (To be__thrown what_is_thrown) 


43 


{ 


44 


printf(**% s was thrown\n*\ 


45 


what_is_t hrown . m cssageQ); 


46 


} 


47 


} 


48 


void catchallQ 


49 


{ 


50 


try 


53 


{ 


52 


doitO; 


53 


} 


54 


catch(. . .) 


55 


{ 


56 


printf("Something unknown was lhrown\n"); 


57 


} 


58 


} 


59 


void maybe_throw(consi char *s) 


60 


{ 


61 


if (strcmp(s l "Whatever") —0) 


62 


{ 


63 


throwfTo be thrown ("Gotcha!")); 


64 


} 


65 


} 



45 



Here is an example of extracted code that would use the 
JSRC instruction. The catchall( ) function is called from 
somewhere else, and is at the top of the call chain, for 
purposes of the example here and in FIG. 7. 

50 The first instance in the program at which the JSRC 
instruction would be utilized, is the first call point (line 24) 
at which exception context information is utilized. The 
information would include for this example how to destruct 
foo__l, how to restore the stack-frame (registers, etc.) from 

55 "middleman( )", including how to find a return address. For 
line 25, no context information is needed because the 
function wont_throw will not throw any exceptions, as can 
be seen from the no-throw "throw( )" attribute in its decla- 
ration. At the next call point (line 26), context information 

60 is stored. At this point context information is needed for how 
to destruct foo_2, how to destruct foo_l, how to unwind 
the stack- frame from " middle man( )", and including how to 
find a return address. The next call-point is to the standard 
function "stracpy( )" at line 33, but since it never throws 

65 exception (known by the compiler or from declaration in its 
header file not included here), no context information is 
needed, so the normal JSR call instruction is used. The call 
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point after that is the function f(s) at line 34. The context where new objects are allocated from. The construction of 

information for this call point includes how to restore the the temporary object must be guarded from the exceptions, 

stack frame from "indirect( )" including how to find a return possibly by adding a state variable (Tempi nCrea lion) that is 

address for indirect. Next, exception context information is normally false, but only true when creating a temporary 

utilized for the "middleman( )" call at line 40. This infer- 5 object. The algorithm then proceeds to set a function context 

mation catches the class to be thrown, states where to copy equal to the current length location of the point of the throw 

the thrown object and the location of the handler, states how or rethrow. The accumulated context is set equal to no 

to restore the stack frame from the "doit( )" function registers to restore and the exceptions in progress variable is 

including how to find a return address. The next call point at incremented (block 802). Next, the try block context is set 

which an exception context information is stored is the 10 equal to the try block context of function context (block 

"doit( ) M call at line 52 in catchall( ). At this point, the 803). For the example in FIG. 7, this is the context of the 

context information indicates that it catches anything, iden- function where the "throw" is executed; "maybe_throw( )" 

tifies the location of the handler, and states how to restore the around line 713. 

stack-frame, including how to find a return address. In this For each pair in the object list of the try block context, as 
example, there is an exception being thrown at line 63. At 15 indicated at block 804 the destructor for such object is called 
this point, the thrown object is created. Jhe r search for a; (block 805). When these operations call destructors or copy 
handler and'the stack unwinding starts Since this code does constructors, those calls must make sure that they do not let 
not contain other exception information, the stack is through any exceptions. This can be accomplished by wrap- 
unwound looking for relevant exception information. ping the calls in the effects of a "try {[cail]}catcb( . . . ) 

FIG. 7 illustrates the growth of the stack according to the 20 {terminate( );}" block, 

example code discussed above. Thus, in this example the After the destructors are called, the handler list is searched 

process starts by a call to the "catchall" function. The stack of the try block context for a handler that matches the object 

grows with a return address of the caller at line 700 and save to throw (block 806). At block 807, a decision is provided 

registers that "catchall" will clobber at line 701. The "catch- based on whether a handler is found. From the flow chart, it 

all" routine calls the "doit" function. The stack^grows by 25 may look like function exception declarations are not 

^storing the return address into "catchall" at line 702,-saved ; asserted. However they are supposed to be implemented by 

^registers that are clobbered by "doit" at line 703 and reserves the compiler adding an implicit try block to be the outermost 

storage for the object "what__is_thrown" at line 704 which of the function, that catches any violations, and transforms 

will be filled in when the exception is thrown, and a them into calls to "unexpectedo", "terminate( )" or into the 

matching try block is found here. The "doit" function calls 30 effect of "throw std::bad_exception'\ 

the middleman function. The stack grows at this point with If the handler is not found at block 807, then the algorithm 

the return address into "doit" (line 705), saves registers that determines whether the try block context is the outermost of 

"middleman" will clobber at line 706, and reserves storage the function context at block 808. If it is the outermost then 

for the objects foo_l and foo_2 in line 707 and 708. The the algorithm transitions to block 809. At this point the 

"middleman" function calls the "indirect" function. When 35 function context is added to the accumulated context. This 

this occurs the stack grows by storing the return address into operation is the collecting of the effects of restoring registers 

"middleman" at line 709, registers that "indirect" will clob- and accumulating adjustments to the stack pointer. They do 

ber at line 710, and storage for the local array "s" at line 711. not have to be carried out immediately, but effects have to be 

The function "maybe_throw" is also called. At this point the remembered and carried out before the jump to the handler, 

return address into "indirect" is stored at line 712 and 40 Also at this block, the function context is set equal to the 

registers that "maybe_throw" will clobber which are known outer function context as a function of the current function 

at the point of the throw are stored at line 713. When in context. This is the location of the use of the invention. The 

maybe_lhrow, the conditions for throwing an exception are "outer function context" is found using the code word in the 

met, and an object of type "To_be_thrown" is thrown. The context-call-instruction, whether the context is coded in the 

stack-unwinding, and search for an exception handler, use 45 code word or in a pointer to a table with the context 

the context information related to the saved return address. information. The "OuterFunctionContext( )" function is the 

The immediate context of the throwing function, that is, same as the function of program counter fi(PC) illustrated in 

saved registers and offset of the return address of the caller, FIG. 7. Thus, the arrow 720 of FIG. 7 represents the 

is known at the time of compilation, and can be directly used technique for finding the function context as a function of 

at the "throw". 50 the program counter (for example by using the JSRC 

This stack must be unwound using an exception manager instruction) for the first call point encountered in the 

such as illustrated in FIG. 8. At program start as indicated at unwinding of the stack. 

block 800, a parameter Except ionsInProgress is 7xro and the After block 809, the algorithm loops to block 803 to 

exception stack is empty. Using the ExceptionsInProgress repeal the process. In this way, the process unwinds the stack 

counter makes tracking unhandled exceptions simple. Any 55 following the path illustrated in FIG. 7 from arrow 720 to 

exceptions that are not caught in the process will result in the arrow 721 to arrow 722 to arrow 723 to arrow 724, arrow 

counter being non-zero on return. The exception stack data 725, arrow 726, arrow 727, arrow 728 until a try-block with 

structure is used to take care of nested exceptions. That is a "catch" matching the type of the thrown object has been 

sometimes exceptions are thrown during destructor calls found. 

when doing stack unwinding, but taken care of inside of the 60 If at block 808, the try block context was not the outer- 
destructor call. The exception stack enables this type of most of function context, then the try block context is set 
processing. equal to outer try block (try block context), and the algo- 
When an exception is thrown as indicated at block 801, a rithm loops back to block 804 to traverse the new context 
temporary ObjectToThrow is created and the ObjectTo- information. This operation is simply traversing a list, 
Throw is pushed on to the exceptions stack. The storage for 65 whether it is a linked list or a table or other implementation, 
the thrown object is implementation dependent. However, a of the object list and handle list in the context information 
heap should be used, preferably separate from the heap (block 810). 
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If at block 807 a handler was found, then the algorithm 
branches to block 811. At block 811, the objects specified in 
the handler description triple are copied. The Exceptionin- 
Progress counter is decremented by 1, the stack pointer and 
other registers are restored using the accumulated context, 
and the program jumps to the handler. Next as indicated at 
block 812, when the handler exits the try block, the excep- 
tion stack is popped and the destructor for the current object 
to throw is called. The storage for the object to throw is 
deallocated, and the algorithm returns to normal execution. 
If after block 811, the exception is rethrown, then the process 
loops back to the rethrow block at 813. The first step in the 
rethrow block is to determine whether the exception stack is 
empty at block 814. If it is, then the process terminates block 
815. If the exception stack is not empty, then the exception 
object is set to the top of the exception stack (block 816), and 
the process loops to block 802. 

Trie foregoing description of a preferred embodiment of 
the invention has been presented for purposes of illustration 
and description. It is not intended to be exhaustive or to limit 
the invention to the precise forms disclosed. Obviously, 
many modifications and variations will be apparent to prac- 
titioners skilled in this art. It is intended that the scope of the 
invention be defined by the following claims and their 
equivalents. 

What is claimed is: 

1. A data processing system responsive to instructions in 
program code to execute a process and the instructions 
including call points between caller and called instructions 
and instructions for maintaining a stack, and the data pro- 
cessing system comprising: 

instruction fetch logic which fetches the instructions in 
the program code to provide a sequence of instructions 
in response to an instruction pointer, the instructions 
further including first jump instructions with a jump 
address and second jump instructions with a jump 
address together with context information for a portion 
of the stack associated with the corresponding call 
point; 

instruction decode logic, coupled to the instruction fetch 
logic, which decodes a current instruction in the 
sequence for execution, and including logic to detect 
the first and second jump instructions and to skip 
decoding the context information of the second jump 
instructions; 

execution resources, coupled to the instruction decode 
logic, which execute the decoded instructions; 

logic, coupled with the instruction fetch logic, which 
updates the instruction pointer; and 

an exception manager to handle exceptions generated by 
execution of the corresponding called function by 
accessing the context information of at least an asso- 
ciated one of the second jump instructions to unwind 
the stack. 

2. The system of claim 1, wherein the second jump 
instructions include varying amounts of context information, 
and the logic which updates the instruction pointer updates 
the instruction pointer to another instruction in the sequence 
thereby avoiding the varying amounts of context informa- 
tion. 

3. The system of claim 1, wherein the sequence of 
instructions comprises one or more exception handlers char- 
acterized by unwind information used to unwind one or 
more of the called and caller instructions including called 
instructions called via corresponding ones of the second 
jump commands, and wherein the context information of the 



10 



second jump commands comprises at least a subset of the 
unwind information. 

4. The system of claim 1, wherein the sequence of 
instructions comprises one or more context tables charac- 
terized by layout information regarding layout of corre- 
sponding portions of the stack, and wherein the context 
information in the second jump instructions comprises at 
least a subset of the layout information. 

5. The system of claim 1, wherein the context information 
in the second jump instructions comprises a pointer to a 
memory location storing information regarding a context for 
the corresponding second jump instruction. 

6. The system of claim 1, wherein the context information 
in the second jump instructions comprises immediate con- 
text data including: the offset to the return-address of the 

15 caller instruction; registers saved on the stack, and an 
amount of the stack allocated for local variables. 

7. The system of claim 1, wherein the context information 
in the second jump instructions comprises a plurality of 
bytes of data, including a field for specifying a format of the 
plurality of bytes. 

8. The system of claim 7, wherein the field indicates 
whether the plurality of bytes includes immediate context 
data, and whether the plurality of bytes includes a pointer to 
context information m another location. 

9. The system of claim 1, further comprising: 
a compiler-linker for^generating-the-program code from^ 

^source code and the compiler-linker for inserting the 
first jump-instruction with an argument at the call- 
points of the caller to called instructions which do not 
throw exceptions and for inserting the second jump 
instruction with both an argument together with corre- 
sponding context information at each of the call-points 
to called instructions which can throw exceptions. 

10. A method for processing instructions in program code 
in a data processing system and the instructions including 
call points between caller and called instructions and 
instructions for maintaining a stack, and the method for 
processing comprising the acts of: 

storing instructions in program code in addressable 
memory, the instructions including first jump instruc- 
tions with a jump address and second jump instructions 
with a jump address together with context information 
for a portion of the stack associated with the corre- 
sponding call point; 
fetching a sequence of instructions from the memory in 
response to an instruction pointer identifying an 
address in the addressable memory; 
decoding a current instruction in the sequence, including 
detecting the first and second jump instructions and 
skipping decoding the context information of the sec- 
ond jump instructions; 
updating the instruction pointer by a length of the current 
instruction; 

calling an exception manager if conditions for the excep- 
tion are met; and in response to calling the exception 
manager, reading the context information of at least an 
associated one of the second jump instructions at an 
address in the addressable memory determined in 
response to a function of the instruction pointer to 
unwind the slack. 

11. The method of claim 10, wherein the second jump 
instructions include varying amounts of context information, 
and the function of the instruction pointer comprises an 
address based on the instruction pointer minus the corre- 
sponding varying amount of the length of the context 
information in the associated one of the second jump 
instructions. 
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12. The method of claim 10, wherein the context infor- 
mation in the second jump instructions comprises a pointer 
to a memory location storing context data associated with 
the corresponding second jump instruction. 

13. The method of claim 10, wherein the context infer- 5 
maiion in the second jump instructions comprises immediate 
context data including: the offset to the return-address of the 
caller instruction; registers saved on the stack; and an 
amount of the stack allocated for local variables. 

14. The method of claim 10, wherein the context infer- 10 
mation in the second jump instructions comprises a plurality 

of bytes of data, including a field for specifying a format of 
the plurality of bytes. 

15. The method of claim 14, wherein the field indicates 
whether the plurality of bytes includes immediate context is 
data, and whether the plurality of bytes includes a pointer to 
context in another memory location. 

16. The method of claim 10, wherein the sequence of 
instructions comprises one or more exception handlers char- 
acterized by unwind information used to unwind one or 20 
more of the called and caller instructions, and wherein the 
context information of the second jump commands com- 
prises at least a subset of the unwind information. 

17. The method of claim 10, wherein the sequence of 
instructions comprises one or more context tables charac- 25 
terized by layout information regarding layout of corre- 
sponding portions of the stack, and wherein the context 
information in the second jump instructions comprises at 
least a subset of the layout information. 

18. The method of claim 10, further comprising the acts 30 

of: 

providing source code with call points between caller and 

called instructions; 
generating the program code from source code including; 
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inserting the first jump instruction with an argument at 
the call-points of the caller to called instructions 
which do not throw exceptions; and 
inserting the second jump instruction with both an 
argument together with corresponding context infor- 
mation at each of the call-points to called instruc- 
tions which can throw exceptions. 
19. A development system to generate program code from 
source code and to execute the program code, and the 
development system comprising: 

a compiler-linker for generating the program code from 
source code and the compiler-linker for inserting a first 
jump instruction with an argument at the call-point of 
a calling function to a called function which does not 
throw exceptions and for inserting a second jump 
instruction with both an argument together with corre- 
sponding context information at each call-point to 
called functions which can throw exceptions and said 
compiler-linker further for generating instructions to 
maintain a stack; 
logic for executing the program code including the argu- 
ments of the first and the second jump instructions and 
for avoiding the execution of the context information of 
the second jump instructions during normal processing; 
and 

an exception manager to handle the throwing of excep- 
tions by the corresponding called function by accessing 
the context information of the associated second jump 
instruction to determine the layout of an associated 
portion of the stack thereby to unwind the associated 
portion of the stack. 

* * * * * 
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